Embodiments in accordance with the present invention generally relate to serving requests, and handling messages and resource access, for industries such as the telecommunications industry, using technologies such as Web services, SIP, Java® (a registered trademark of Sun Microsystems, Inc., of Santa Clara, Calif.), and Corba® (a registered trademark of Object Management Group, Inc., of Needham, Mass.) and more specifically to processing rules, policies, and/or workflows in these technologies.
Policies, typically combinations of selected policy rules, are used for a variety of purposes. For instance, policies are used to authorize or authenticate a user, enforce service level agreements, charge for access or usage, allocate resources, and determine which services a subscriber or user is allowed to access, including privacy policies, usage policies, preferences, etc. Such policies are used, for example, by telecommunication companies, wireless service enablers, Internet service providers (ISPs), information technology (IT) vendors, network equipment vendors, and application developers.
Policies typically include a combination of conditions and actions. In existing service provider networks, policies typically are evaluated or enforced using a rule set language. Rule set languages are typically optimized for the specific application for which they are used, and as such are extremely efficient for use in evaluation of policies, such as in the evaluation phase of a Policy Decision Points (PDP)/Policy Enforcement Points (PEP) model. Rule set models are also relatively simple to implement, manage, and optimize. A potential drawback to the use of rule set models, however, is that the typical implementation of a policy as a rule set is rather restrictive in functionality, such as in an extensible Access Control Markup Language (XACML) implementation. In fact, a rule set typically only supports the evaluation of a first condition, followed by the execution of a single action (or a limited number of actions associated with a different condition). This does not provide the desired combination of any condition with any action. There is a limited ability to develop rich and flexible expressions, such as topology of a programmable flow between the rule sets with loops, conditions, and actions that may affect the flow.
Such simple implementation or topologies may be suitable for some network level decisions (e.g., for switches) that tend to not require complex procedures, but instead require high speed and/or efficiency. Currently, some flexible expressions are required in control level policies, such as IP Multimedia Sub-System (IMS) policies, which mix low latency requirements with the need for some expression power. At a higher level of need for expression power are service level policies, such as execution environment policies and enabler/service exposure policies, which may occur in Web services, for example. Another example includes policies that support the flows of a content delivery suite, such as are described in U.S. patent application Ser. No. 11/138,844, entitled “PLATFORM AND SERVICE FOR MANAGEMENT AND MULTI-CHANNEL DELIVERY OF MULTI-TYPES OF CONTENTS”, filed May 25, 2005, and U.S. patent application Ser. No. 11/357,652, entitled “SERVICE LEVEL DIGITAL RIGHTS MANAGEMENT SUPPORT IN A MULTI-CONTENT AGGREGATION AND DELIVERY SYSTEM,” filed Feb. 16, 2006, each of which is hereby incorporated herein by reference.
As described in U.S. patent application Ser. No. 11/024,160, incorporated by reference above, for example, policies may also be implemented as workflows in a business process modeling language (BPML), such as BPEL (Business Process Execution Language). Policies with business rules may be manually integrated into a BPEL process by adding activities, which model the consumption and production of messages, tasks, data, or goods. However, the manual integration of rules is inefficient, and it is not easy for the developer to handle complex rules and deal with the impact of dynamically changing rules. As such, BPEL is well suited for modeling delegation and complex combinations of business processes, but has limitations in implementing policies
Further, while the requirements on policy evaluation and enforcement may differ for each policy level, consistency across these policy levels is essential. The same policy, or parts thereof, may exist on each level, such as on network/transport, session control and/or signaling, and service levels. For example, as one expands the service level (layer) for service providers, more and more functions previously provided in the lower layer may also partially or totally be provided in the service level (e.g. service level charging). It is therefore essential to consistently model policy rules across levels (e.g. to avoid double/multiple charging or to ensure consistent charging/charging correlation across levels). Consistent policy rules and engines also are needed for provisioning resulting policies in the service provider domain and in service-oriented architecture (SOA) to separate business rules and consistently model composition of resources.
Existing systems fall short of various goals behind policy enforcement, including: (1) provide a single enabler and set of interfaces to manage all service provider policies (at least at the service level) and move away from silos; (2) provide formalism to author/manage policies throughout a service provider domain; (3) assure interoperability across vendors; (4) assure interoperability across actors (e.g. letting an enterprise or third party content or service provider delegate some policy evaluation and enforcement steps to the service provider, letting an authorized principal load/send/configure policies on a terminal); (5) stabilize/rationalize (i.e., allow evolutionary approaches, migration, etc.) the policy management, evaluation and enforcement and the policy modeling across any evolution of the SP domain (e.g., evolving/changing vendors, evolving/changing network/resource technologies, evolving/changing policy needs, evolving/changing or new services with different policy implications, etc); (6) facilitate the development of policy authoring tools and development, deployment and management environment; and (7) facilitate the reuse of a common policy formalism for enablers/resources/services and other standard bodies.
Other drawbacks of existing implementations of policies include: limitations of the combination of conditions of actions that can be achieved; limitation of the scope to too narrow domain; limitations of the extensibility (e.g. what kind of condition or action can be expressed); portability; interoperability; modeling and support of delegation; implementation complexities; impact on legacy systems and deployed solutions; implications for policies already specified by resources; and impact of implementation reuse.